Scenario-Based Generation of Digital Library Services

ions and notations for the domain at hand. They do not support specific DL patterns, models, and methodologies. There are few software toolkits available to build DLs. As a result, most DLs are custom-built using homegrown architectures without making use of conceptual modeling, requirements analysis, and methodological approaches. The general trend has been to develop tools to solve small parts of the problem, whereas the root of the problem – the lack of specific DL patterns, models, methodologies, formalisms, and languages – is almost completely ignored. DLs are either built as monolithic, tightly integrated, and generally inflexible systems or by assembling components. The lack of models and processes for constructing these systems results in problems in interoperability and adaptability. For full-service, large-scale digital libraries to develop and interoperate with others, a fair degree of standardization is required. Such standards must rest on some agreed-upon framework and reference model, building upon careful definition of requirements [10]. The process of requirements analysis helps the DL designer capture the functional requirements of a software system through the creation of structural and behavioral models represented by DL “societies” and “scenarios”. Scenarios are key artifacts in systems engineering, but their management is poorly understood. Scenarios are a good communication base with naive users and other non-technical people and support early validation of requirements at a low abstraction level A scenario-based design approach to DL development is lacking in current DL toolkits and prototyping tools. This also hampers the ability to tailor DL components and behaviors to particular user communities. Recent work on DLs has shown that they can be built by connecting small components that communicate through a family of lightweight protocols, using XML as the data interchange mechanism [11]. This work successfully attempts to provide a solution to the interoperability problems facing DLs, however it still leaves certain questions unanswered such as: How are DLs built when components do not follow protocols? How are DLs built when services cannot be modeled as components?